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System and Method for Detecting Fraudulent Calls 

This application is a continuation-in-part of U.S. Application No. 09/948,729 

filed on September 7, 2001; and U.S. Application No. (Attorney Docket 

No. 20375-008700US), entitled Money Transfer Evaluation Systems and Methods, and filed 
5 on . 

BACKGROUND OF THE INVENTION 
[01] This invention relates generally to the field of monitoring transaction systems to 
identify suspicious activity. 

[02] Toll free authorization request numbers are typically provided to various merchants. 
|0 Some merchants share toll free authorization request numbers while other merchants have 
^ their own private authorization request numbers. These authorization request numbers are 
□ intended to be used by merchants to phone in authorizations when a card fails at the point of 
m sale. Using these numbers allows a merchant to continue with a sale when a given card can 

not be read electronically. 
Q 5 [03] Unfortunately, fraud sometimes takes place when certain individuals are able to learn 
H\ these authorization request numbers. These individuals may have computer-generated, stolen 
3 or otherwise obtained a potential account number. The individuals use the potential account 

numbers to call an authorization service, via an authorization request number, in order to 

ascertain whether the potential account number is authorized for a given dollar amount. 
20 These fraudulent calls are often made from home phones, cell phones, pay phones, etc. Once 

the individuals learn that a potential account number is authorized, they may attempt to use 

the potential account number on the Internet, in a mail order, in a telephone order, in an in 

person transaction. 

BRIEF SUMMARY OF THE INVENTION 
25 [04] The present invention includes systems and methods for evaluating transactions to 

determine if suspicious behavior exists. In some embodiments, the systems and methods are 
used to identify potentially and, in some cases, imminent fraudulent activity, such as that 
relating to credit card transactions. In other embodiments, the systems and methods provide 
for sharing information across a plurality of system types to identify suspicious activity. 
30 [05] In one embodiment of the present invention, probable fraudulent activity is 

determined. An authorization request for a given dollar amount is received at a receiving 



center from a user. Using a fraud test, it is determined if the authorization request is likely to 
be indicative of fraudulent activity. 

[06] An investigation area is coupled to the receiving center. The investigation area 
houses a fraud detection processing system. The fraud test can be run at the investigation 
5 area on the fraud detection processing system. A determination is made as to whether the 
dollar amount falls within a certain threshold. This determination can be considered to be a 
part of the fraud test in one embodiment. If the dollar amount is within a certain threshold, 
then at the investigation area the fraud test, or further fraud testing, is run on the authorization 
request to determine if fraudulent activity is likely. 
dO [07] The receiving center communicates to the user whether or not the dollar amount is 
• \ authorized. This information is obtained when the receiving center communicates with a 
'■£} management center, which in turn communicates with an appropriate bank. 
1*1 [08] If it is determined at the investigation area that there is a likelihood of fraud, then this 
[I is communicated to the bank via the receiving center and the management center, 
iil 5 Appropriate action can then be taken. 

[09] In one embodiment, the fraud test can comprise determining an originating phone 
P number, wherein the originating phone number is the phone number from which the 
O authorization request originated, and comparing the originating phone number against a good 
u list of legitimate originating phone numbers. If the originating phone number is not matched 
20 with a number in the good list, the originating phone number can be compared against a bad 
list of illegitimate originating phone numbers. If the originating phone number is matched 
with a number in the bad list, the originating phone number can be flagged as probably 
related to fraudulent activity. It is also envisioned that the originating phone number can be 
compared against the bad list before the good list. 
25 [10] The fraud test can also include any one of: determining if at least one other 

authorization request has a dollar amount equivalent to the dollar amount of the authorization 
request; determining if the authorization request is for an even dollar amount; determining if 
the authorization request occurs at a time that falls within one or more red flag time windows; 
determining if at least one other authorization request occurs within a red flag time of the 
30 authorization request; and determining if a given number of authorization request occurs 
within a given time frame from the same originating phone number. 
[11] Various embodiments include methods for evaluating transactions for suspicious 
activity. Such methods include providing a reference designator list that includes data, or 
information associated with suspicious activity. In some instances, the data is a subset of 
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information available from a particular transaction system. The reference designator list is 
used to evaluate transactions occurring on a first and a second transaction system. In some 
embodiments, additional data, or information, is received from the first transaction system 
and incorporated into the reference designator list. Some embodiments further include 
5 receiving information from the second transaction system and incorporating it into the 

reference designator list. In particular embodiments, the added information is incorporated 
into the reference designator list by creating a new reference designator, associating the 
added information with the new reference designator, and adding the new reference 
designator to the reference designator list. 
10 [12] In one particular embodiment, the first transaction system is involved in responding to 
r j authorization requests, while the other transaction system is involved in money transfers. 

Such a first transaction system can implement reception of an authorization request, 
111 determination of the origin of the authorization request, and comparison of the authorization 

request with information in a reference designator list. 
4=5 [13] Various systems in accordance with the present invention include a first and second 
□ transaction system associated with a fraud detection system. In some embodiments, the first 
5| transaction system can be a credit authorization system, while the second transaction system 
is a money transfer system. 

[14] The summary provides only a general outline of the embodiments according to the 
20 present invention. Many other objects, features and advantages of the present invention will 
become more fully apparent from the following detailed description, the appended claims and 
the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[15] Fig. 1 is one embodiment of a fraud warning system. 
25 [16] Fig. 2 is a flowchart of one embodiment of a method of determining probable 
fraudulent activity. 

[17] Fig. 3 A is a flowchart describing a server process. 
[18] Fig. 3B is a continuation of the flowchart of Fig. 3A. 
[19] Fig. 4 shows the fields used by an export file. 
30 [20] Fig. 5 illustrates subsystems of an exemplary computer system for use with the 
present invention; 
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[21] Fig. 6 illustrates a money transfer system that can be evaluated in accordance with 
embodiments of the present invention; 

[22] Fig. 7 illustrates a fraud watch system in accordance with an embodiment of the 
present invention; 

5 [23] Figs. 8a-8b illustrate an exemplary transaction record, where Fig. 8a is the forst 
portion of the record and Fig. 8b is the second portion of the same record; and 
[24] Fig. 9 illustrates and exemplary reference designator list in accordance with 
embodiments of the present invention. 

M DETAILED DESCRIPTION OF THE INVENTION 

if D [25] Particular aspects of the present invention provide systems and methods for 

Si monitoring and detecting fraudulent activity. Such fraudulent activity can include, but is not 

limited to, detecting fraudulent money transfers, fraudulent calls, and/or fraudulent credit 
m card uses. In some embodiments, the fraud is detected by using information derived from a 
!L plurality of fraud detection systems. In one particular embodiment, a reference designator list 
15 is developed from information obtained from two fraud detection systems. The reference 
ji designator list can then be used to search a database associated with a money transfer system 
if to detect prior fraudulent activity, and/or used in a real time situation to detect ongoing 

fraudulent activity. For example, the reference designator list can be queried in real-time 
whenever a request is made to a receiving center to request an authorization. 
20 [26] Activity can be identified as suspicious by a variety of systems. Such suspicious 
activity can then be provided to systems and methods in accordance with the present 
invention that maintain a central accessible repository of suspicious activity. The central 
repository can be used in real-time to evaluate ongoing activity in light of the previously 
detected suspicious activity to determine if the ongoing activity is illegitimate. Systems and 
25 methods useful in identifying suspicious activity can include those disclosed in U.S. Patent 

Application No. (Attorney Docket No. 020375-008400US), entitled Systems 

and Methods for Monitoring Credit Fraud, and filed on ; U.S. Patent 

Application No. (Attorney Docket No. 020375-008700US), entitled Money 

Transfer Evaluation Systems and Methods, and filed on ; U.S. Patent 

30 Application No. (Attorney Docket No. 020375-008900US), entitled Systems 

and Methods for Monitoring Credit Card Transactions, and filed on . All 

of the foregoing references are incorporated herein by reference for all purposes. 
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[27] Other aspects of the present invention provide systems and methods for monitoring 
authorization requests related to credit card transactions. Some aspects of monitoring 
authorization requests involve receiving authorization requests at a transaction center, 
investigating the authorization request, and either approving or denying the authorization 
5 request based on the results of the investigation. 

[28] As shown in the exemplary drawings wherein like reference numerals indicate like or 
corresponding elements among the figures, an embodiment of a system according to the 
present invention will now be described in detail. The following description sets forth an 
example of a fraud detection system and methodology. The system can be operated on many 

10 different computing platforms, and other variations should be apparent after review of this 

p description. 

!j{ [29] Referring to Fig. 1, one exemplary embodiment of a fraud warning system 100 is 
W illustrated. A receiving center 102 for receiving communications from merchants is coupled 
py to a management center 104. The management center is in turn coupled to at least one bank 
% 106. As used herein, the term "bank" refers to a bank, financial institution, credit issuer, 
C credit/charge card company or the like. 

p [30] In keeping with aspects of the invention, receiving center 102 is coupled to an 
:={ investigation area 108 that houses a fraud detection processing system. The receiving center 
111 can receive authorization requests 1 10 from users (e.g., merchants, etc.). Such authorization 
20 requests are typically received by a telephone call from the merchant. Conveniently, the 

receiving center may include an interactive voice response unit where all calls may be 

handled in an automated manner. 

[31] Referring to Fig. 2, in operation, receiving center 102 receives an authorization 
request for a dollar amount from a user (block S200). At this point, it is communicated to the 

25 user as to whether or not the dollar amount is authorized. The authorization request also 
includes an account number for the credit card and optionally the expiration date. This 
authorization request is typically but not necessarily in the form of a phone call to a toll free 
number. However, it is contemplated that other suitable forms of communication, such as 
computers and networks, can be used as well. Each merchant who subscribes to the subject 

30 services is assigned one or more toll free numbers. 

[32] As mentioned above, sometimes the criminal element steals or generates these 
numbers and attempts to commit fraud. The criminals typically make an authorization 
request for a low amount (usually less than $100) to see if the account number, credit card, 
etc., is authorized for use. The reason for the criminal element trying to authorize a low 
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dollar amount is so that as much credit is still available as possible. Once the criminals 
receive authorization they typically use the account number to commit fraud by making a 
purchase. However, it will be appreciated that fraudulent activity may occur with larger 
requests, and the invention may be modified to screen these calls as well. 
5 [33] A determination is made as to whether the dollar amount falls within a certain 
threshold (block S202). This determination can be made at receiving center 102 or 
investigation area 108. If the dollar amount is within a certain threshold (e.g., $0 to $100), 
then a fraud test will be run on the authorization request to determine if fraudulent activity is 
likely afoot. If not, no further fraud testing is done in one embodiment, and the authorization 

110 request is processed as normal. In other embodiments, a fraud test may be run on all 
transactions, or the threshold could be increased, e.g., to $250. In some embodiments, 
determination of whether the dollar amount is within a certain threshold is part of the fraud 

0 test. 

jj! [34] A fraud test is run at investigation area 108 (block S204). It should be noted that the 
*15 aspects of the fraud test can be implemented in software, hardware, manually, or by any 
Uf suitable combination thereof The fraud test typically is run in investigation area 108 using 
the fraud detection processing system. In one embodiment, the fraud test may comprise any 
3 combination of the following: determining an originating phone number and comparing it 

against a good list of legitimate originating phone numbers; determining an originating phone 
20 number and comparing it against a bad list of illegitimate originating phone numbers; 
determining if multiple authorization requests made from the same phone number have 
equivalent dollar amounts; determining if the authorization request is for an even dollar 
amount; determining if the authorization request occurs at a time that falls within one or more 
red flag time windows; determining if at least one other authorization request occurs within a 
25 red flag time of the authorization request; determining if a given number of authorization 
requests occur within a given time frame from the same originating phone number; and the 
like. Based on this fraud test, it is determined whether there is probable fraudulent activity 
(block S204). 

[35] In one embodiment, the time during which the authorization request 110 came into 
30 receiving center 102 is determined and considered. As an example, if the authorization 

request came into the receiving center at 7:00 a.m. in the time zone of the receiving center, 
then the next step might be to determine where (including what time zone) the authorization 
request originated from. One way this might be determined is to look at the area code of the 
originating phone number. If it is determined that the authorization request came in it was 



6 



also 7:00 a.m. at the place from which the authorization request originated, then this might 
not be indicative of fraudulent activity. On the other hand, if the authorization request came 
in at 5:00 a.m. at the place from which the authorization request originated, then this might be 
indicative of fraudulent activity. 
5 [36] In another embodiment, the fraud test begins by comparing the originating phone 
number (or other information indicative of where the authorization request originated from) 
with a list of known legitimate phone numbers. If the originating phone number is not 
matched with a number in the legitimate list, the originating phone number is then compared 
against a list of known illegitimate originating phone numbers. If the originating phone 

10 number is matched with a number on the illegitimate list, the originating phone number might 
be flagged as probably related to fraudulent activity. Additionally, the originating phone 

% number can be added to the illegitimate list. 

Ill [37] The call from the originating phone number (or other communication) can be further 

o 

ill investigated if the originating phone number was flagged as probably related to fraudulent 
ia f5 activity. The originating phone number can be determined in any suitable manner, such as by 
O using a caller ID system as mentioned above. It is also envisioned that the originating phone 
'Pi number (or other information indicative of where the authorization request originated from) 
%\ can be compared against the illegitimate list before being compared against the legitimate list. 

[38] Any suitable method of analyzing the results from above can be used to determine 
20 probably fraudulent activity. As used herein, "probable fraudulent activity," "likely to be 
indicative of fraudulent activity," "probably related to fraudulent activity" and the like refer 
to a certain threshold of estimated likelihood that the authorization request came from a 
source having criminal intent (e.g., not an authorized merchant). This threshold can be 
changed as desired. Moreover, various levels of probable fraudulent activity can be 
25 determined if so desired. One possible manner of determining if there exists probable 
fraudulent activity is to assign weights or points to the results of the various blocks 
mentioned above. 

[39] Further, an investigative interface (e.g., a person) is determined (block S206). This 
person might query various public and private data bases and conduct proactive investigation 
30 (calls the originating phone number in a pretext call) in order to ascertain ownership and 

control of the phone number. This way the person can verify whether that phone number is 
related to the merchant account which is involved in the "suspect" transaction which has 
previously qualified under the fraud search rules as a suspect transaction and as probably 
being indicative of fraudulent activity. This person, or investigator, then "marks" the 
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transaction and therefore the telephone number (or other authorization request) as good or 
bad. If it is determined at investigation area 108 that there exists probable fraudulent activity, 
then this is communicated to the appropriate bank 106 via receiving center 102 and the 
management center (block S208). Thus, bank 106 is warned that further fraud is imminent. 
5 Appropriate action can then be taken, such as performing a more thorough investigation and 
contacting the authorities and the fraud victim. 

[40] Figs. 3 A and 3B are flow diagrams of a process according to embodiments of the 
present invention. The call interactive voice response database 300, which can be within the 
receiving center 102, can send nightly batch jobs 302 that contain data related to the 

10 authorization requests 110. The data is transferred via SFTP to a Fraud Detection Server 304, 

u which is coupled to a Fraud Detection Database 306. 

Ci [41] Periodically, a fraud detection process is started; i.e., a fraud test is run (block S308). 
J! Fraud warning system 100 then checks for import files (block S3 10). In one embodiment, at 
;JJ approximately every minute with the exception of the hours between 1 :00 a.m. and 3:00 a.m. 
1 5 when backups and file transfers are taking place, fraud warning system 100 checks for new 
T import files at a pre-determined directory of Fraud Detection Server 304. If multiple files are 
y present, fraud warning system 100 will process them one at a time. If no files are present, 
O fraud warning system 100 continues on to the next task in the loop. If a file is present (block 
74 S3 12), then fraud warning system 100 checks for invalid records (block S3 14). The field 
values can be checked for invalidity based on a validation number assigned to the field. A 
count of the invalid and valid records is taken and stored. Records that pass the data 
cleansing process are imported into the database running on the Fraud Detection Server 304 
(block S3 16). 

[42] In one embodiment; all historical caller ID or event origin phone number (or "ANI") 
25 records with an update date of 1 80 days from the current date, whether good or bad, can be 
removed or purged from an ANI table (block S3 18). All historical records from a Raw Data 
Table with an authorization request (or "ARU") date over 180 days can be deleted. 
[43] Following the purge, all incoming records are checked against the ANI Table to 
determine if the incoming event ANI has already been identified as good or bad. Then the 
30 good and bad ANI are flagged (block S320). If the ANI is good then the record is removed 
from the Raw Data Table. If, on the other hand, it is a known bad ANI (or "KBA") then it is 
categorized as such. Once a record is flagged as KBA, then in some embodiments, it will not 
be deleted by another process. 



[44] In one embodiment, if the total events per credit master ID (e.g., the first six digits of 
a credit card number, or "BIN") is two or less and the time span between them is less than 
two minutes and it is the same card number and it is not marked KBA, then the calling event 
is most likely valid. If an event is determined to be valid, it can be deleted from the Raw 
5 Data Table (block S322). The logic is that if a card number is entered incorrectly the first 
time, a second event will show up for the same card shortly thereafter. 
[45] In one embodiment, if the total number of calls per BIN is greater than two, and the 
card numbers match for the first twelve digits, and the time between calls is less than or equal 
to five minutes, and the ANI is the same, then the event is categorized as credit master (or 

10 "CRM"). This type of activity suggests card numbers were automatically generated and 

f possibly in the form of an automated dialing system. These credit master events are flagged 
Q (block S324). 

f [46] Flagging skimmed lost stolen (or "SLS") events (block S326) requires sorting the 
CI current Raw Data by ANI and comparing the area code of the incoming records with the area 
iff) codes of KBA's previously identified. This can be done because certain area codes 
;L, statistically have a higher rate of fraud associated with them, and therefore generate more 
■4.1 consistent matches for this particular type of activity. The count of events must also be 

11 greater than or equal to a given number (e.g., three) for each ANI. 

[47] Once this first subset of records has been selected, they can be looped through and a 
20 second subset of data can be created for each ANI keyed by BIN. This is run through another 
loop that checks to see if within this subset the BIN numbers are different, the amounts are 
within, for example, five cents of each other and the time of the calls were within, for 
example, five minutes of each other. Each time these requirements are met, a count is 
incremented by one. If after processing all the records in the ANI subset this count is greater 
25 than or equal to, for example, all events for that ANI and associated BIN's are categorized as 
SLS. 

[48] All event times can be saved in a certain time zone, e.g., Central Time Zone where 
fraud warning system 100 is located. Then, a calculation can be made based on the ANI's 
area code to determine the correct time of the event (block S328). 
30 [49] Following the corrected event time, fraud warning system 100 can check the event 
time to see if the transaction took place at an odd hour for the ANI local. If the event hour is 
between, for example, 3:00 a.m. and 5:00 a.m., then it may be categorized as AFH (block 
S330). In one embodiment, this categorization may be left out of the process. 
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[50] At this point, the remaining uncategorized records are theoretically valid and of no 
interest. These unprocessed events are purged from the Raw Data Table (block S332). The 
events that remain in the Raw Data Table can be assigned client numbers, or reference 
designations as discussed later (block S334). The client number can be determined by taking 
5 the first six digits of the card number, or the BIN. Alternatively, the client number can be the 
ANI. 

[51] In order for events to be selected from a client interface, the last server import process 
appends the current import files' date(s) to the available dates table (block S336). This 
import file may then be moved to backup (block S338). Then, fraud warning system 100 can 
10 run a check to find errors, if any (block S340). If there is no error, then the process returns to 

check for import files (block S3 10). Otherwise, the process goes to the error module (block 
O S342). If there is a nonfatal error, then a system administrator is notified. If there is a fatal 

error, then the process stops. 
;=( [52] If no file is present (block S312), then event mail is checked (block S1314). Event 
1 5 mail is similar to a batch file but contains information for only one bad ANI. If there is an 
J event mail (block S 1 3 1 6) then a BatchSend Table is purged (block S 1 3 1 8). Continuing on, 
|; j there is an option to create either an Excel or a delimited file (block S 1320) which allows 
"~ clients to use data themselves. Then the file is encrypted (block SI 322), an E-mail is created 
3 (block S 1 324), and the file is attached to the E-mail and sent (block S 1 326) to the client or 
2b other designee based on client-provided information. The BatchSend Table is then updated 
(block S1328). Then an error check is run as before (block SI 330). If there is no error, it 
returns to B. If an error is found, the process goes to the error module (block S 1342). 
[53] Turning now to Fig. 3B, a check is done for daily batch mail (block S344), because 
the mail may be in the form of a batch file containing information related to multiple events 
25 instead of a single event. The process then runs as before, with blocks S346 to S360 
corresponding with blocks S1316 to S1328, respectively. 

[54] If there is no batch mail, then the database is queried for the last application running 
time (block S362). If it is time to send an E-mail to the administrators to let them know fraud 
warning system 100 is still up and running, then the database is queried for the administrators 
30 E-mail list (block S366). The confirmation E-mail created (block S368) and sent (block 

S370). Then fraud warning system 100 can enter a sleep mode for a predetermined period of 
time (block S372), and later return to check for import files (block S3 10). 
[55] Fig. 4 shows fields included in the fields used by an export file. The nightly batch job 
302 generates these fields. These fields contain data related to the authorization requests. 
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These fields include: the Caller ID phone number, the card number, the authorization request 
date, the time of the authorization request, the dollar amount requested, the DNIS, the 
merchant number, and the approval number, if any. 

[56] Fig. 5 illustrates subsystems found in one exemplary computer system that can be 
5 used in accordance with embodiments of the present invention. Computers can be configured 
with many different hardware components and can be made in many dimensions and styles 
(e.g., laptop, palmtop, server, workstation and mainframe). Thus, any hardware platform 
suitable for performing the processing described herein is suitable for use with the present 
invention. This hardware can be used, for example, in investigation center 108 for analyzing 
10 information to determine if fraudulent activity is likely. 

u . [57] Subsystems within are directly interfaced to an internal bus 210. The subsystems 

include an input/output (I/O) controller 212, a system random access memory (RAM) 214, a 
if j central processing unit (CPU) 2 16, a serial port 220, a fixed disk 222 and a network interface 
if adapter 224. The use of the bus allows each of the subsystems to transfer data among the 
15 subsystems and, most importantly, with CPU 216. External devices can communicate with 

CPU 2 1 6 or other subsystems via bus 2 1 0 by interfacing with a subsystem on bus 210. 
H [58] Fig. 5 is illustrative of one suitable configuration for providing a system in accordance 
p with the present invention. Subsystems, components or devices other than those shown in 
*4 Fig. 5 can be added without deviating from the scope of the invention. A suitable computer 
&0 system can also be achieved without using all of the subsystems shown in Fig. 5. Other 
subsystems such as a CD-ROM drive, graphics accelerator, etc., can be included in the 
configuration without affecting the performance of system 100 included in the present 
invention. 

[59] One embodiment according to the present invention is related to the use of an 
25 apparatus, such as the computer system, for implementing a simulator according to 

embodiments of the present invention. CPU 216 can execute one or more sequences of one 
or more instructions contained in system memory 214. Such instructions may be read into 
memory 214 from a computer-readable medium, such as fixed disk 222. Execution of the 
sequences of instructions contained in memory 214 causes CPU 216 to perform the process 
30 blocks described herein. One or more processors in a multi-processing arrangement may also 
be employed to execute the sequences of instructions contained in the memory. In alternative 
embodiments, hard- wired circuitry may be used in place of or in combination with software 
instructions to implement the invention. Thus, embodiments of the invention are not limited 
to any specific combination of hardware circuitry and software. 
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[60] The terms "computer-readable medium" and "computer-readable media" as used 
herein refer to any medium or media that participate in providing instructions to CPU 216 for 
execution. Such media can take many forms, including, but not limited to, non- volatile 
media, volatile media and transmission media. Non-volatile media include, for example, 
5 optical or magnetic disks, such as fixed disk 222. Volatile media include dynamic memory, 
such as memory 214. Transmission media include coaxial cable, copper wire and fiber 
optics, including the wires that comprise bus 210. Transmission media can also take the form 
of acoustic or light waves, such as those generated during radio frequency (RF) and infra-red 
(IR) data communications. Common forms of computer-readable media include, for 
10 example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic 
IHJ medium, a CD-ROM disk, DVD, any other optical medium, punch cards, paper tape, any 

□ other physical medium with patterns of holes a RAM, A PROM, an EPROM, a 

ill 

ifj FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium 

from which a computer can read. 
® [61] Various forms of computer-readable media may be involved in carrying one or more 
m sequences of one or more instructions to CPU 216 for execution. The bus carries the data to 
ti memory 214, from which the processor retrieves and executes the instructions. The 
ii| instructions received by the memory can optionally be stored on fixed disk 222 either before 
ij or after execution by the processor. 

20 [62] Many subsystem configurations are possible. Fig. 5 is illustrative of but one suitable 
configuration. Subsystems, components or devices other than those shown in Fig. 5 can be 
added. A suitable computer system can be achieved without using all of the subsystems 
shown in Fig. 5. 

[63] As presented, Figs. 1-5 illustrate embodiments for evaluating credit card authorization 
25 activity to identify suspicious and/or fraudulent activity using fraud warning system 100. In 
accordance with other embodiments of the invention, detection of suspicious and/or 
fraudulent activity can be coordinated between two or more transaction systems. Thus, as an 
example, fraud warning system 1 00 can be utilized in conjunction with information obtained 
from a money transfer system, or the like. As an illustration, Figs. 6-9 illustrate an 
30 embodiment of the present invention where fraud warning system 100 is used in conjunction 
with a money transfer system. It should, however, be recognized that any two or more 
systems can be used in accordance with the present invention. Thus, among others, two 
money transfer systems, two fraud warning systems 100, two credit card monitoring systems, 
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two cellular phone evaluation systems, or a combination thereof can be monitored in 
accordance with the present invention. 

[64] Referring to Fig. 6, a money transfer system 1 100 is comprised of an interface system 
1125, an automatic teller system ("ATM") system 1145, a deposit maintenance network 
5 1 150, a credit maintenance network 1 160 and a central exchange 1 170. Interface system 
1 125 is communicably coupled to ATM system 1 145 via an ATM network 1 140, deposit 
maintenance network 1150 and credit maintenance network 1 1 60. In general, interface 
system 1 125 unifies a variety of transfer systems while supporting a variety of mechanisms 
for introducing and receiving information to and/or from money transfer system 1 100. 
1 0 [65] Interface system 1 1 25 comprises a transaction center 1130 and one or more terminals 
M 1 1 1 0 in communication via a transaction network 1 120. Transaction network 1 1 20 can be 
A any communication network capable of transmitting and receiving information in relation to a 
S j transfer of value from one entity to another. For example, transaction network 1 120 can 
P comprise a TCP/IP compliant virtual private network (VPN), the Internet, a local area 
Wp network (LAN), a wide area network (WAN), a telephone network, a cellular telephone 

network, an optical network, a wireless network, or any other similar communication 
m network. In particular embodiments, transaction network 1 120 provides message based 
If communications between terminals 1110 and transaction center 1130. 
if [66] Terminals 1110 can be any terminal or location where value is accepted and/or 
20 provided in relation to money transfers across money transfer system 1 1 00. Thus, in some 
instances, terminal 1 1 10 is a convenience store where a clerk can receive value from a sender 
and initiate transfer of the value to a receiver via money transfer system 1 100. In such cases, 
the clerk can typically also provide transferred value to a receiver. 

[67] In other instances, terminal 1 1 10 is an automated system for receiving value from a 
25 sender for transfer via money transfer system 1 100 and/or for providing value to a receiver 
that was transferred via money transfer system 1 100. To accommodate various different 
payment instruments and types, terminal 1 1 10 can include a variety of interfaces. For 
example, terminal 1110 can include a mechanism for receiving cash, credit cards, checks, 
debit cards, stored value cards and smart cards. Such terminals may also be used at the 
30 payout end to print a check or money order, or to credit a cash card or stored value card. 
Examples of such terminals are described in copending U.S. Application No. 09/634,901, 
entitled "POINT OF SALE PAYMENT SYSTEM," filed August 9, 2000 by Randy J. 
Templeton et al., which is a nonprovisional of U.S. Prov. Appl. No. 60/147,899, entitled 
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"INTEGRATED POINT OF SALE DEVICE," filed August 9, 1999 by Randy Templeton et 
al, the complete disclosures of which are herein incorporated by reference. 
[68] In yet other instances, terminal 1 1 1 0 is a personal computer operated by a sender of 
value. Such a terminal can be communicably coupled to transaction center 1 1 30 via the 
5 Internet. The terminal can further include a web browser capable of receiving commands for 
effectuating transfer of value via money transfer system 1 100. 

[69] Terminal identification information can be associated with each terminal 1110. Such 
identification information includes, but is not limited to, a physical location, a telephone 
number, an agent identification number, a terminal identification number, a security alert 

1 0 status, an indication of the type of terminal, a serial number of a CPU, an IP address, the 
name of a clerk, and the like. 

5 [70] Using money transfer system 1 100, value can be transferred from any of a number of 
points. For example, value can be transferred from terminal 1 1 10 to itself or any other 

r! terminal 1110, from any terminal 1 1 1 0 to a deposit account via deposit maintenance network 

'% 1 150 or credit maintenance network 1 160, from any terminal 1 1 10 to any ATM 1 1 14 via 

'»" ATM network 1 140. Many other transfers to/from ATMs 1 1 14, deposit accounts, terminals, 
and/or credit accounts can be accomplished using money transfer system 1 1 00. 

O [71] Referring to Fig. 7, a fraud watch system 1210 is provided in communication with 

Q transaction center 1 130 of money transfer system 1 100, and with fraud warning system 100. 

50 Thus, according to some embodiments of the present invention, fraud detection information 
developed in fraud warning system 100 can be utilized to detect suspicious money transfers 
proceeding on money transfer system 1 100 and, in converse, fraud detection information 
developed in association with money transfer system 1 100 can be utilized to detect suspicious 
authorization requests handled by fraud warning system 100. 

25 [72] As illustrated, transaction center 1130 includes a network processor 1 1 32 to process 
data received and transmitted via transaction network 1 120. Data to/from network processor 
1 132 is available to a host 1 1 33 that may communicate with one or more of a value translator 
1 135, a transaction database 1 136, a settlement engine 1 137 and a messaging engine 1 138 to 
perform functions associated with transferring value via money transfer system 1 100. In 

30 turn, messaging engine may communicate with a message translator 1 139. The received 
and/or provided by transaction center 1130 may include information on the sender, 
information on the recipient, identification information associated with a terminal 1110, the 
type and amount of value transferred, a desired location to transfer the value, and the like. In 
some cases, a value translator 1135 may be used to change the type of value. For example, 
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value translator 1 135 may do a foreign currency conversion, or may transfer from one type of 
value to another, e.g. frequent flyer miles to United States' Dollars. All information that is 
processed may conveniently be stored in transaction database 1 136. 

[73] Settlement engine 1137 may be used to facilitate the crediting and debiting of various 
5 accounts during a transfer. For example, if a sender requests that funds from a credit card 
account be used in the transfer, settlement engine 1 137 is used to contact credit maintenance 
network 1 160 to charge the card and to manage the fees involved in the transaction. Such 
fees may be those charged by the credit organization as well as internal fees that are a part of 
the money transfer transaction. Settlement engine 1137 may be used in a similar manner 

1 0 when crediting or debiting checking accounts, stored value accounts, customer loyalty points 
! ^ and the like. 

'B [74] Once a value transfer is properly processed, data indicating the transfer is sent by a 
j| j switch 1 1 34 to the appropriate network as shown. This may be to ATM network 1 1 40, 
CI deposit maintenance network 1150 and/or credit maintenance network 1 1 60 to complete the 
J 5 transaction. 

%, [75] Fraud watch system 1210 includes a fraud processing server 1 220 and a watch 

database 1230. Fraud watch system 1210 is associated with transaction system 1 130 in a 

11 manner that allows for access to transaction database 1136. Such association can be provided 
3 by direct wired communication between transaction database 1 136 and fraud processing 

20 server 1220, by direct or network communication between transaction center 1 1 30 and fraud 
processing server 1220, or by any other mechanism that provides fraud watch system 210 
with access to transaction database 1136. In one particular embodiment, fraud processing 
server 1220 is communicably coupled to transaction network 1120 and accesses transaction 
database 1 136 via network processor 1 132 and host 1 133. In another embodiment, fraud 

25 processing server 1220 is directly coupled to host 1 133 and accesses transaction database 

1 136 via host 1 133. It will be recognized by one of ordinary skill in the art that a number of 
other mechanisms exist within the scope of the present invention for providing access by 
fraud processing server 1220 to transaction database 1 136. 

[76] Fraud processing server 1220 can be any microprocessor based device capable of 
30 retrieving data from transaction database 1 136, searching and manipulating the data, 

maintaining a form of the data on watch database 1230, and providing access to data on 
database 1230. Such access to the data can include formatting the data and providing the data 
in an easily accessible form. In some embodiments, fraud processing computer is a single 
computer, such as a personal computer or a database server. In other embodiments, fraud 
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processing server is a group of two or more computers. In such embodiments, fraud 
processing computer can include a central computer associated with one or more peripheral 
computers. Such peripheral computers can be personal computers or portable devices, such 
as lap top computers and/or personal digital assistants. In a particular embodiment, fraud 
5 processing server 1220 includes a SQL server, while in other embodiments, it includes an 
ORACLE server. 

[77] Fraud processing server 1220 includes a computer readable medium capable of 
maintaining instructions executable to perform the functions associated with fraud processing 
server 1220. The computer readable medium can be any device or system capable of 
10 maintaining data in a form accessible to fraud processing computer 1220. For example, the 
M : computer readable medium can be a hard disk drive either integral to fraud processing server 
1220 or external to the server. Alternatively, the computer readable medium can be a floppy 
disk or a CD-ROM apart from fraud processing server 1220 and accessible by inserting into a 
=p drive (not shown) of fraud processing server 1220. In yet other alternatives, the computer 
-15 readable medium can be a RAM integral to fraud processing server 1220 and/or a 

microprocessor (not shown) within the server. One of ordinary skill in the art will recognize 
Lil many other possibilities for implementing the computer readable medium. For example, the 
: computer readable medium can be a combination of the aforementioned alternatives, such as, 

a combination of a CD-ROM, a hard disk drive and RAM. 
20 [78] In some embodiments, transaction database 1136 maintains a record of money 

transfer activities associated with money transfer system 1100. An exemplary embodiment 
of such a record of money transfer activities 1300 is illustrated in Figs. 8a-8b. Referring to 
Fig. 8a, record 1300 includes a schema 1305 outlining the type of data maintained for each 
money transfer transaction. The types of data can include: a sender's last name, sNameLast 
25 301; a sender's middle name, sNameMiddle 1303; a sender's first name, sNameFirst 1307, a 
sender's phone number, sPhone 1309; a sender's address, sAddress 1311; the type of agent 
used by a sender, sAgentType 1313; the agent's identification number, sAgenfNumber 1317; 
the date a transfer was requested, sDate 1319; the amount of the requested transfer, 
sAmountln 1321; the type of value, sValueTypeln 1323; the cost of the transfer, 
30 sTransactionCost 1327; a receiver's last name, rNameLast 1329; a receiver's middle name, 
rNameMiddle 1331; a receiver's first name, rNameFirst 1333, a receiver's phone number, 
rPhone 1337; a receiver's address, rAddress 1339; the type of agent used by the receiver, 
rAgentType 1341; the agent's identification number, rAgentNumber 1343; the date a transfer 
was received, rDate 1347; the amount of the received transfer, rAmountOut 1349; and the 
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type of value received, rValueTypeOut 1351. It should be recognized that, within the scope 
of the present invention, any number of data types can be included in record 1300. 
[79] As illustrated in Figs. 8a-8b, record 1300 further includes a number of specific 
instances 1310, 315, 1320, 1325, 1330, 1335, 1340, 1345, 1350, 1355 of schema 1305. As 

5 described in detail in U.S. Patent Application No. (Attorney Docket No. 

020375-008700US), entitled Money Transfer Evaluation Systems and Methods, previously 
incorporated by reference for all purposes; the various instances in record 1300 can be 
analyzed, and based on the analysis a record designator list 1500 as illustrated in Fig. 9 can 
be developed. 

|0 [80] Reference designator list 1500 can be used to analyze transactions as discussed in the 
previously referenced patent application. For example, reference designator list 1500 can be 
!fH used is used in relation with database management tools to access various money transfer 
w records within transaction database 1 136 that, based on the reference designators, appear to 
:]fj be suspect. 

'%5 [81] In accordance with embodiments of the present invention, reference designator list 
UJ 1 500 can also be used in relation with fraud warning system 1 00 to detect fraudulent 
== authorization requests. More particularly, reference designator list 1 500 can be accessed by 
y fraud warning system 100, and utilized in relation to methods previously described with 

reference to Figs. 2-3. For example, in block S204, the tests run in investigation area 108 can 
20 include comparing the determined originating telephone number with the various telephone 
numbers provided in reference designator list 1 500. If a match is found, additional 
investigation may be performed, or, in some instances, the authorization may simply be 
denied because it is associated with a cluster of inter-related activities that appear suspicious. 
[82] In various embodiments of the present invention, phone numbers identified as 
25 suspicious in fraud warning system 100 are incorporated into reference designator list 1500. 
Thus, for example, where a telephone number identified on fraud warning system 100 is not 
already associated with a reference designator within reference designator list 1500, a new 
reference designator is created, associated with the telephone number received from fraud 
warning system 100, and added to reference designator list 1500. Thus, when reference 
30 designator list 1500 is used in relation to either fraud warning system 100 or money transfer 
system 1 100, indicators of fraudulent activity from both systems is available for use in 
detecting suspicious activity. 

[83] At this juncture, it should be recognized that information from a variety of fraud 
detection systems can be incorporated into a reference designator list to provide a 



17 



comprehensive approach to fraud detection. Furthermore, the types of data shared between 
detection systems is not limited to telephone numbers, or even the information illustrated in 
reference designator list 1500. For example, fraud warning system 100 can additionally 
provide credit card numbers that are suspicious, names of suspicious users, and other relevant 
5 information. Yet further, other fraud detection systems may provide additional information 
that is unique to the particular fraud detection scheme yet warrants inclusion in a common 
reference designator list. 

[84] The invention has now been described in detail for purposes of clarity and 
understanding. However, it will be appreciated that certain changes and modifications may 

1 0 be practiced within the scope of the appended claims. Thus, although the invention is 
described with reference to specific embodiments and figures thereof, the embodiments and 

1 1 figures are merely illustrative, and not limiting of the invention. Rather, the scope of the 
= ' invention is to be determined solely by the appended claims 
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